WebRTC Provider

WebRTC peer-to-peer implementation for UTCP

The WebRTC provider enables UTCP to establish peer-to-peer connections for real-time communication, allowing for direct data exchange between clients without requiring a central server for data transfer. This is ideal for applications requiring low-latency, direct communication between peers.

Configuration

WebRTC providers are configured using the following JSON structure:

{
  "name": "p2p_service",
  "provider_type": "webrtc",
  "signaling_server": "wss://signaling.example.com/socket",
  "peer_id": "server-endpoint-123",
  "data_channel_name": "tools",
  "ice_servers": [
    {
      "urls": ["stun:stun.l.google.com:19302"]
    },
    {
      "urls": ["turn:turn.example.com:3478"],
      "username": "user",
      "credential": "pass"
    }
  ],
  "connection_timeout": 30000,
  "ordered": true,
  "max_retransmits": 3
}

Configuration Fields

Field	Required	Description
`name`	Yes	Unique identifier for the provider
`provider_type`	Yes	Must be set to `"webrtc"`
`signaling_server`	Yes	WebSocket URL of the signaling server
`peer_id`	Yes	ID of the peer to connect to
`data_channel_name`	No	Name of the data channel (default: `"tools"`)
`ice_servers`	No	STUN/TURN servers for NAT traversal
`connection_timeout`	No	Connection timeout in milliseconds (default: `30000`)
`ordered`	No	Whether messages should be delivered in order (default: `true`)
`max_retransmits`	No	Maximum number of retransmissions (default: `3`)

Signaling Process

WebRTC requires a signaling mechanism to establish connections. The process typically works as follows:

1

Connection to Signaling Server

Both peers connect to the signaling server via WebSocket

2

Offer Creation

The client initiates a connection request with an offer

3

Answer Response

The server responds with an answer to the offer

4

ICE Candidate Exchange

ICE candidates are exchanged to establish the best connection path

5

Direct Connection

Once established, data flows directly between peers

Message Format

Messages sent over the WebRTC data channel should follow a standard format:

Tool Call Message

{
  "type": "tool_call",
  "tool": "tool_name",
  "id": "unique-call-id",
  "inputs": {
    "param1": "value1",
    "param2": "value2"
  }
}

Tool Response Message

{
  "type": "tool_response",
  "tool": "tool_name",
  "id": "unique-call-id",
  "output": {
    "result": "value"
  }
}

Tool Discovery

For WebRTC providers, tool discovery can happen in two ways:

Via Signaling Server

The initial tool definitions are provided through the signaling server during the connection handshake.

After Connection

Tool definitions are requested after the WebRTC connection is established using the data channel.

Examples

Real-time Gaming

{
  "name": "game_p2p",
  "provider_type": "webrtc",
  "signaling_server": "wss://game-signal.example.com/socket",
  "peer_id": "game-server-789",
  "data_channel_name": "gamedata",
  "ordered": true,
  "max_retransmits": 0,
  "ice_servers": [
    {
      "urls": ["stun:stun.l.google.com:19302"]
    }
  ]
}

Collaborative Editing

{
  "name": "document_collaboration",
  "provider_type": "webrtc",
  "signaling_server": "wss://collab.example.com/signal",
  "peer_id": "doc-server-456",
  "data_channel_name": "document",
  "ordered": true,
  "connection_timeout": 60000,
  "ice_servers": [
    {
      "urls": ["stun:stun.l.google.com:19302"]
    },
    {
      "urls": ["turn:turn.example.com:3478"],
      "username": "collab_user",
      "credential": "secure_pass"
    }
  ]
}

Video Conference Integration

{
  "name": "video_conference",
  "provider_type": "webrtc",
  "signaling_server": "wss://meet.example.com/signal",
  "peer_id": "conference-room-123",
  "data_channel_name": "controls",
  "ordered": false,
  "max_retransmits": 1,
  "connection_timeout": 45000
}

Security Considerations

Encryption

• WebRTC uses DTLS for data channel encryption
• All peer-to-peer traffic is encrypted by default
• Signaling server should use secure WebSocket (WSS)

Authentication

• Verify peer identity during signaling
• Use secure credentials for TURN servers
• Implement application-level authentication

Best Practices

Connection Management

• Maintain long-lived connections for frequent interactions
• Implement connection health monitoring
• Handle connection failures gracefully

Performance

• Configure appropriate STUN/TURN servers
• Use reliable mode when ordering is required
• Implement fallback mechanisms for connection failures